The invention relates to a Generalized-Multi-Protocol Label Switching, GMPLS, controlled network and in particular to enhancements to the GMPLS RSVP-TE protocol for managing transport services under conditions of disrupted control plane connectivity.
The Generalized-Multi-Protocol Label Switching, GMPLS, is a protocol suite extending MPLS to manage further classes of interfaces for switching technologies other than packet interfaces and switching such as time division multiplex, layer 2 switch, wavelength switch and fiber switch. The Generalized MPLS differs from the traditional MPLS in that it supports multiple types of switching. Generalized-Multi-Protocol Label Switching, GMPLS, can, for example, form a control plane of a wavelength switched optical network. Currently, the GMPLS RSVP-TE protocol is widely deployed in GMPLS control transport networks. The GMPLS is composed of three main protocols comprising the Resource Reservation Protocol with Traffic Engineering extensions RSVP-TE signalling protocol, an Open Shortest Path First with Traffic Engineering extensions OSPF-TE routing protocol and the Link Management Protocol LMP. The Resource Reservation Protocol-Traffic Engineering RSVP-TE protocol is an extension of the Resource Reservation Protocol RSVP for Traffic Engineering. It supports the reservation of resource across an IP network. The RSVP-TE protocol is detailed in IETF RFC3209 updated by RFC5151 and generally allows the establishment of MPLS Label Switching Paths (LSPs) taking into consideration network constraint parameters such as available bandwidth and explicit path specification. The GMPLS RSVP-TE protocol (RFC3473) is deployed in GMPLS controlled transport networks. The RSVP-TE protocol works well on IP/MPLS networks. However, on transport networks, the RSVP-TE protocol poses some operational disadvantages when used for dynamic service provisioning in the network.
The GMPLS RSVP-TE protocol is a soft state hop-by-hop protocol. When a service controlled by the GMPLS RSVP-TE protocol needs to be manipulated, for example, set up or torn down, a signalling message is initiated on the service ingress node of the service and forwarded hop-by-hop via transit nodes from the service path to the egress node of the respective service. At the service egress node the message flow is reversed and the message is forwarded back also hop-by-hop via the transit nodes to the ingress node as illustrated in FIG. 1. As can be seen in FIG. 1 the signalling message such as the shown Path message is sent from the ingress node of the service to the egress node and then Resv message is sent back from the egress node to the ingress node of the service. The Path message traverses from the ingress node to the egress node whereas the Resv messages traverse from the egress node to the ingress node. The signalling message (Path or Resv) is processed on a node before it is forwarded by the node along the service path to the next neighbouring node. When the signalling message flow completes the loop back to the ingress node and has been processed by the ingress node, the operation is completed and the management plane of the network is notified about the completion status of the service comprising a success status or a failure status.
At times, when the service does not experience any changes or modifications, all nodes involved in the respective service send and receive periodic Path and Resv refreshes as illustrated by FIG. 2. These periodic refreshes comprise a Path message with unmodified content to the downstream neighbouring node towards the egress node or a Resv message which with unmodified content to the upstream neighbouring node towards the ingress node along the service path. These refreshes according to the protocol mean to say that as far as the node having sent the message is concerned, the service is alive, unmodified and functioning.
FIG. 2 illustrates the GMPLS RSVP-TE refreshing process between an upstream node and a downstream node along the signal path of the service. The downstream refresh messages sent by the upstream node to the downstream node refresh the Path state whereas the upstream refresh messages sent by the downstream node to the upstream node refresh the Resv state of the service. The refresh messages are sent regularly, for instance, every 30 seconds.
FIG. 3 illustrates a situation where a disrupted control plane connectivity in a network using a conventional GMPLS RSVP-TE protocol has occurred. In the shown example of FIG. 3 a service controlled by the GMPLS RSVP-TE protocol starts at node A, ends at node E and takes a service path via transit nodes B, C and D. Accordingly, node A forms the ingress node and node E forms the egress node of the respective service. Nodes B, C, D are transit nodes along the signal path of the service. In a situation where the service has been established and a transit node such as node C has stopped functioning, RSVP-TE protocol speaking nodes B and D do quickly detect this fact because they stop receiving signalling refreshes Resv and Path respectively from the failing node C. Node C may fail in the shown example because of a software bug, a hardware failure, a configuration error or a maintenance procedure at node C. Since nodes B, D do not receive refreshes from node C both transit nodes B and D realize that neighbouring node C is inaccessible. The missing refreshes from node C indicate a disruption in the control plane connectivity, in particular the RSVP-TE connectivity. In conventional IP/MPLS networks missing refreshes also automatically mean the disruption in the data plane, i.e. that the respective service has stopped transferring user data. This is because IP/MPLS routers send each other RSVP-TE message “in band”, this means that they use the same network resources to transfer control plane messages and user data thus having a 100% fate sharing. Therefore, a situation such as shown in FIG. 3 does not present a problem on a conventional IP/MPLS network. In such an IP/MPLS network the neighbouring nodes B and D at the failed node C simply initiate a disfunctional service release in both directions. Node D does tear down the tail of the service by issuing a PathTear message in downstream direction towards the egress node E, while node B does tear down the service head by triggering a PathErr flow in the upstream direction towards the ingress node A. As soon as the PathErr message is processed on the service ingress node A, the management plane and the operator are notified about the service release and the reason as to why this service release was necessary. In contrast, on a transport layer network, such as a WDM network, the situation such as shown in FIG. 3 is problematic. The neighbouring nodes B and D do detect missing refreshes from the failed node C and the control plane connectivity disruption. This detected fact does not mean that the service has stopped delivering user traffic. This is because transport network elements deliver RSVP-TE packets “out of band” via a separate Data Communication Network DCN. In fact, probabilistically there is a good chance that the service is still healthy and transferring the user data normally. Therefore, unlike in the case of a conventional IP/MPLS network, the neighbouring nodes B and D of the failed node C in this case are not allowed to tear down the service. Indeed, nodes of conventional GMPLS RSVP-TE implementations do nothing in such a situation except for logging the fact that they have stopped receiving the signalling refreshes from their neighbouring node such as node C as shown in FIG. 3. Furthermore, the conventional GMPLS RSVP-TE protocol provides currently no way for the neighbouring nodes B or D to notify the service ingress node A about the detected disruption in the control plane connectivity with a consequence that this fact will go unnoticed by the operator of the network.
If in such a situation the operator wants, for example/to tear down the service as illustrated in FIG. 4 this would be problematic. A tear down of the service is done by triggering a PathTear message from the service ingress node A. The PathTear message would be propagated only as far as node B, where, after several attempts to send it to the non-responsive node C, node B would give up and stop, leaving the respective service in a state where the head segment, i.e. nodes A and B, is released while the tail segment, i.e. nodes C-D-E, is strayed. Again, the conventional GMPLS RSVP-TE protocol used in transport networks currently provides no way to notify the service ingress node A about the fact that the service release has not been fully completed, hence this fact will also go unnoticed. If in such a situation the operator of the network tries to set up a new service starting possibly from a different ingress node that relies on some of the strayed resources, i.e. tail segment D-E, this attempt will fail. Even after the non-responsive node C comes up back into service, no automatic release of the strayed resources is performed. Because the service head segment, i.e. nodes A, B has been removed, node C does not receive any Path refreshes for the service from node B. However, node C does not have any information as to why these refreshes are missing. It may be that the service is active but node B is currently down or the Path message is lost because of some DCN problems. Therefore, no automatic release of the service will be attempted.
As shown in FIG. 4 if the control plane connectivity between node B and C and between node C and D is disrupted, modify messages and teardown messages cannot traverse beyond node B as explained above. Accordingly, networks using a conventional GMPLS RSVP-TE protocol can face serious operational problems under conditions of disrupted control plane connectivity. These operational problems are complex and difficult to understand for the operator of the network. Moreover, these operational problems caused by disrupted control plane connectivity are not easy to fix because they require some lengthy in-depth investigation by a highly qualified personnel and a manual cleanup that is also prone to configuration errors.
Accordingly, it is an object of the present invention to provide a method for a network which overcomes the above-mentioned problems caused by a disrupted control plane connectivity.